在上一篇文章提到減少使用縮寫這件事，我覺得值得再深入討論一下這個主題。
語言是會隨著時間不斷演化的，也會跟著文化慢慢融入其他的國家或次文化的用語，所以任何一個「字」都有可能突然演化成一個正式的專有名詞。
我在說的就是"ID"。
在維基百科裡，ID的檢索還是很保守，它寫"ID, Id, id or I.D."，基本上己經看到他的整個演化過程，從保留縮寫點，到兩個字都大寫，到接受d是小寫。

如果查字典的話，在有些字典裡，ID也同時可以當成名詞，以及動詞化使用

所以，縮寫這件事並不是壞事，當我們看到縮寫時，也不應該是要皺著眉頭，捏著鼻子要求寫的人一定要修改，而是要更進一步的了解這些縮寫

1. 是否己被通俗使用
2. 是否有意義
3. 是否有達到縮寫的意義（三個字縮成兩個字基本上是沒什麼意義的)

這些具備通俗意義的字，在絕大多數（嗯，我不敢把話說死）的情況下還是會用縮寫的，例如

• IT通俗縮寫，例如http, ftp, ip, pc, ascii, ram, cpu...這些字基本上就算是靠字數來賺錢的課本也只會出現兩到三次的全稱
• 開發通俗縮寫，例如html, css, api, dll, png, sql, json, xml，大家都是業界人士就不用多說了吧
• 約定成俗的縮寫，例如國名，城市名，還有幣值，這些基本上也都常用縮寫。

為什麼我不敢把話說得那麼死，說這些是可以直接使用縮寫？因為縮寫太容易發生碰撞了，例如說IP，除了當成Internet Protocol外，也可以當成Intellectual Property(智慧財產權)。愈短的縮寫愈有可能發生碰撞，甚至有些專案是故意發生碰撞的，這時候就可能用其他的縮寫，或直接用全稱來取代。

理解了縮寫，那在開發時會遇到什麼問題:

命名

我的問題是，我想也是很多成熟的開發團隊會規定的事：那縮寫要用什麼方法來命名?應該要叫UserID還是UserId（或是User_Id/User-Id)?

還是那句老話，如果團隊有共識，就用共識決。例如像SQL，微軟就很直接的把他當成一個字。

但我的建議是：如果他己經被接受成一個字了，那他就應該被視作一個"單字"，例如ID即然他己被做為專有名詞使用，那就應該寫成UserId。

應用

那不是一個字的縮寫怎麼辦?應該是

    var xMLParser = new XMLParser();

還是

    var xmlParser = new XMLParser();

從上面的例子可以看出來，同大同小應該是比較適當的：保留他的全大寫或全小寫樣式，也比較可以辨視出來這個詞其實是個縮寫字。

共識

團隊裡應該要有一個大表，把可以接受的縮寫字列出來，最少最少要把無法產生共識的詞列出來，例如像grp，有些團隊可以接受這種縮寫，這種內隱知識(Tacit knowledge)就應該被文件化，讓現在或未來的團隊理解這東西的存在。

一致性

產生了共識，就應該要一致，在程式裡的所有詞（前後端服務資料庫）都應該使用這個詞，也應該當成Code review或Pull request的檢核點之一。

一個縮寫也有那麼多功課在裡面，做為未來的專業人士的你怎麼能不快點把字典找出來呢?分享一下你看過最有趣的縮寫吧!

延伸閱讀:
論文寫作：同樣是縮寫，abbreviation、acronym和initialism有何不同？
英文縮寫小知識

接下來是廣告時間：我很想多接觸一些比較資淺的開發人員，所以我想藉此推廣我的鐵人賽文章，也想幫助那些正在看鐵人賽文章，想寫好程式，也想在未來三到五點有些改變的人。
我目前有個計劃，叫100 days resolution，是想鼓勵在台灣的軟體工程師到北美工作，把三個最重要的東西用100天好好準備:英文,技能還有履歷，讓自己有更好的空間可以發展。
但目前這個粉絲專業我己經建好，但還沒有任何的東西在上面，未來我會開始分享一些美加地區軟體工作的相關資訊，以及英文學習及履歷優化的重點。
有興趣的話歡迎加入 :)